Universal authentication token

ABSTRACT

A universal authentication token is configured to securely acquire security credentials from other authentication tokens and/or devices. In this manner, a single universal authentication token can store the authentication credentials required to access a variety of resources, services and applications for a user. The universal authentication token includes a user interface, memory for storing a plurality of authentication records for a user, and a secure processor. The secure processor provides the required cryptographic operations to encrypt, decrypt, and/or authenticate data that is sent or received by universal token. For example, secure processor may be used to generate authentication data from seed information stored in memory.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.60/737,660, filed Nov. 16, 2005, which is herein incorporated byreference in its entirety.

FIELD OF THE INVENTION

This application relates generally to data communications and morespecifically to information security.

BACKGROUND OF THE INVENTION

Many service or application providers require a user to presentauthentication information in order to gain access to a specific serviceor application. For example, an employer may require an employee toenter a one-time password to access computer resources remotely. In afurther example, the provider of on-line financial services may requireusers to enter authentication data to gain access to financialinformation or perform transactions. In addition, a token may berequired to gain physical access to a building or a location within abuilding.

Authentication factors for individuals are generally categorized inthree classes: something the user is (e.g., a biometric such as afingerprint), something the user has (e.g., a security token), andsomething the user knows (e.g., a password). Many sensitive services andapplications require multi-factor authentication. That is, a user mustprovide multiple authenticators in order to gain access to a resource,service, and/or application.

A typical security token uses a symmetric cryptography algorithm toprovide authentication credentials. For example, the token and theverifying entity (e.g., a network server or building access controller)may both maintain or generate the same value (e.g., using a particularalgorithm and seed).

Because of the need for strong security, an individual may have multiplesecurity tokens. For example, a user may have a security token whichgenerates a code to enable the individual to gain access to a buildingvia an entry security system. The same individual may have a separatetoken to generate passwords that enable the individual to access hiscompany's computer resources and another token to generate securitycredentials to enable the access to on-line financial accountinformation.

Requiring a separate token for multiple services is inconvenient forusers and increases the likelihood that a user will not fully utilize aservice or application. In addition, increasing the security burden on auser often results in the user handling the one or more tokens in aninsecure manner or developing mechanisms to avoid or bypass security alltogether.

What is therefore needed is a universal authentication token which canimport and store authentication data from other authentication tokens.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate the present invention and, togetherwith the description, further serve to explain the principles of theinvention and to enable a person skilled in the pertinent art to makeand use the invention.

FIG. 1 is an exemplary operating environment for the use andprovisioning of universal authentication tokens, according toembodiments of the present invention.

FIG. 2 depicts a block diagram of an exemplary universal authenticationtoken, according to embodiments of the present invention.

FIG. 3 depicts a flowchart of a method for provisioning a universalauthentication token, according to embodiments of the present invention.

FIG. 4 depicts a flowchart of an exemplary certificate-basedchallenge/response protocol, according to embodiments of the presentinvention.

FIG. 5 depicts an exemplary flowchart of a method for authenticating theuser of the universal token, according to embodiments of the presentinvention.

FIG. 6 depicts a flowchart of a method for using a universalauthentication token, according to embodiments of the present invention.

The present invention will now be described with reference to theaccompanying drawings. In the drawings, like reference numbers canindicate identical or functionally similar elements. Additionally, theleft-most digit(s) of a reference number may identify the drawing inwhich the reference number first appears.

DETAILED DESCRIPTION OF THE INVENTION

A universal authentication token is configured to securely acquiresecurity credentials from other authentication tokens and/or devices. Inthis manner, a single universal authentication token can store theauthentication credentials required to access a variety of resources,services and applications for a user. For example, a single universalauthentication token may be used to access a data network, gain accessto financial information such as an on-line financial account, gainaccess to a building, perform a transaction (e.g., using a credit cardnumber or information used by a smartcard), gain access to a localcomputing device, or to perform other authentication operations that mayuse, for example, authentication credentials such as one-time passwords,HID codes, etc.

FIG. 1 is an exemplary operating environment 100 for the use andprovisioning of universal authentication tokens, according toembodiments of the present invention. Exemplary operating environment100 includes a plurality of universal authentication tokens 102(referred to herein as “universal tokens”), one or more authenticationtokens 104, one or more devices 106 storing authentication data, one ormore access devices 110, a communications network 120, and one or moreservers 130.

Server 130 hosts one or more resources, applications, and/or services towhich a user is enrolled. Server 130 includes one or more resources,applications, and/or services (not shown) and one or more authenticationrecords 132 associated with each resource. A server may comprisehardware and/or software configured to provide a resource, service, orapplication. For example, a server may include a processing system thathandles access requests, authenticates the requestor, and facilitatesaccess to the requested resource, service, or application.

A user enrolls with a service provider, employer, building owner, etc.(collectively referred to herein as “provider” for ease of description)for access to a specific resource, service, application, or physicallocation (collectively referred to herein as “resource” for ease ofdescription). After performing verification and authentication of theuser, the provider issues an authentication token 104, device 106, ordata file including the authentication data required for future accessto the resource. In addition to issuing the authentication mechanism,the service provider stores an identifier for the user and his/herassociated authentication data in the authentication record 132 for theresource.

Access device 110 includes a reader 112 and a network interface 116.

Reader 112 is configured to communicate with a universal token 102and/or authentication tokens 104. Specifically, reader 112 is configuredto receive (i.e., read) data stored on universal token 102. In anembodiment, reader 112 is a contact-based reader. In a contact-basedreader, the reader has one or more electrical connectors which makecontact with electrical connectors on universal token 102. An example ofa contact-based reader is a smart card reader in which the smart cardmust be inserted into a slot to establish connection between the chip onthe card and the reader.

In addition or alternatively, access device 110 may include acontactless reader 114. A contactless reader 114 communicates with auniversal token 102 wirelessly. For example, the contactless reader 114may communicate with a universal token 102 using radio frequencyidentification (RFID) induction technology, low frequency RFID, or nearfield communication (NFC) such as high frequency RFID, ISO 14443 and ISO15693).

In an embodiment, access devices 110 directly access one or more servers130 via a communications medium 120. Communications medium 120 may be apublic data communications network such as the Internet, a private datacommunications network, the Public Switched Telephone Network (PSTN), awireless communications network, or any combination thereof. Theinterface between access devices 110 and communications network 120 andthe interface between servers 130 and communications network 120 can bea wireless interface or a wired interface.

Universal authentication token 102 is any user device which can importand store authentication information for multiple resources,applications and/or services including, but not limited to, a fob,dongle, smart card, building access card, badge, or other form of easyto carry article. In addition, universal authentication token 102 can beembedded in a device such as a wireless phone, a personal digitalassistance (PDA), a personal entertainment device (PED) or personalcomputer. A universal token 102 may be implemented in various physicalforms depending upon the needs of the respective application. Forexample, universal token 102 may be circuitry embedded in a smallplastic (or other material) case.

In an embodiment, universal token 102 is used in combination with anaccess device 110 to access a resource provided on a server or othercomputing device. In addition or alternatively, universal token 102 maydisplay a password which is then entered by a user into a computingdevice to gain access to the resource.

Authentication token 104 is a user device which stores authenticationinformation for one or more resources, applications, or services. Unlikeuniversal token 102, authentication token 104 is not configured toimport authentication data from other tokens or devices.

Device 106 is any device which stores authentication information for oneor more resources, applications, or services. In an embodiment, device106 is not portable. For example, device 106 may be a computer systemwhich issues authentication data for a resource, service, orapplication.

Universal token 102 is configured to communicate with authenticationtokens 104 or devices 106 to obtain authentication data stored on thetokens 104 and/or devices 106. Universal token 102 may also communicatewith other universal tokens 102 to obtain authentication data. Thecapability to securely communicate with other authentication tokens 104or devices 106 allows for the consolidation of authentication data for avariety of resources, applications, and/or services onto a singleuniversal token 102. In an embodiment, universal token 102 communicateswith authentication tokens 104 and/or devices 106 via a wirelessinterface including, but not limited to, RF interfaces, opticalinterfaces, RF interfaces, or the like. In addition or alternatively,universal token 102 communicates with authentication tokens 104 and/ordevices 106 via a wired connection.

FIG. 2 depicts a block diagram of an exemplary universal authenticationtoken 102, according to embodiments of the present invention. Universaltoken 102 includes a user interface 205, memory 210, optional biometricauthentication interface 250, secure processor 260, and communicationsinterface 270.

User interface 205 is configured to enable a user to interact withuniversal token 102. User interface 205 may include one or more outputdevices including, but not limited to, a display, indication lights, anda speaker. In addition, user interface 205 may include one or more inputdevices including, but not limited to, a keypad, button, pointingdevice, touch screen, audio device, and/or soft-key-based menu.

Secure processor 260 provides the required cryptographic operations toencrypt, decrypt, and/or authenticate data that is sent or received byuniversal token 102. For example, secure processor 260 may be used togenerate authentication data from seed information stored in memory 210.Secure processor 260 may comprise a processor, memory, dedicatedcryptographic hardware. In addition, secure processor 260 mayincorporate other security mechanisms. In an embodiment, secureprocessor 260 is designed to conform to a security specificationrelating to, for example, FIPS or TPM. In an embodiment, secureprocessor 260 includes a device authentication module 262 and a userauthentication module 264.

A security boundary associated with secure processor 260 may beestablished, for example, using hardware and/or cryptographictechniques. Hardware techniques for providing a security boundary mayinclude, for example, placing components within a single integratedcircuit. In addition, one or more integrated circuits may be protectedby a physical structure using tamper evident and/or tamper resistanttechniques such as epoxy encapsulation. Encryption techniques forestablishing a security boundary may include, for example, encryptingsensitive information before it leaves secure processor 260. For thispurpose, secure processor 260 may use one or more cryptographicprocessors and store the associated encryption/decryption keys in asecure memory internal to secure processor 260.

In an embodiment, secure processor 260 includes the capabilities togenerate an asymmetric key pair (public/private key pair). In analternative embodiment, the private key is “securely injected” into thesecure processor 260. In the secure injection embodiment, the entitywhich injects the private key must “forget” the private key to ensurethe integrity and privacy of the asymmetric key pair. In eitherembodiment, the private key does not leave the hardware securityboundary of processor 260 unless encrypted. An exemplary system andprocess for securely generating an asymmetric key pair or securelyinjecting a private key into a processor is described in detail in U.S.Patent Publication No. 2005/0166051, entitled “System and Method forCertification of a Secure Platform,” which is incorporated herein byreference in its entirety.

Biometric authentication module 250 includes a biometric scanner and/orsoftware to convert the scanned biometric data into a biometrictemplate. In an embodiment, biometric authentication module 250 alsoincludes functionality to authenticate a user. Biometric authenticationmodule 250 is optional. When present, biometric authentication may beused to control access to the universal token 102. In addition oralternatively, biometric authentication may be used to authenticate auser to an authentication token 104 or device 106 or to provide anaddition authentication factor to server 130. In an embodiment,biometric authentication module 250 includes a fingerprint reader orfingerprint scanner. In an embodiment, all or a portion of the biometricauthentication module 250 is included within the security boundary ofsecure processor 260.

Memory 210 is configured to store authentication data and/or data thatmay be used to generate authentication data (collectively referred toherein as “authentication data” for ease of description). For example,memory 210 may store user authentication data 220, token authenticationdata 230, and token-resource authentication data 240. In an embodiment,a portion of this information is stored in a security boundaryassociated with secure processor 260. Memory 210 may include RAM, ROM,flash memory, one-time-programmable (OTP) memory or other types of datastorage devices.

User authentication data 220 includes data for authenticating a user ofuniversal token 102. Universal token 102 may be provisioned for multipleusers.

User authentication data 220 includes one or more user authenticationrecords, each having a user identifier 222 and associated authenticationdata 224. Note that the user identifier may not be present if universaltoken 102 is provisioned for a single user. In an embodiment, userauthentication data 220 is stored within the security boundary definedby the secure processor 260. User authentication data 220 may be ashared secret, a password, or a PIN.

In an embodiment, user authentication data 224 is a biometric templatesuch as a fingerprint template. For example, when universal token 102 isfirst initialized for a user, the token 102 may take a biometric scan ofthe user via biometric authentication interface 250. The biometricauthentication interface 250 then converts the scan data into a formatefficient for storage as user authentication data 224 (e.g., a biometrictemplate). Subsequently, the universal token 102 performs a biometricscan of a potential user. The secure processor 260 may then determinewhether the received biometric template matches the biometric templatestored for the user in memory 210 (i.e., user authentication data 224).If a match is confirmed, the user is allowed access to the functionalityprovided by universal token 102.

Token authentication data 230 includes data to authenticate theuniversal token 102 to other tokens and/or devices. Token authenticationdata 230 includes a public/private key pair 232 assigned to the tokenand a digital certificate 234 for the token. In an embodiment, tokenauthentication data 230 may include one or more secret keys or otherform of secret shared between the token and another device. As describedabove, the private key, secret keys, and/or shared secrets may be storedwithin the security boundary defined by the secure processor 260.

Digital certificate 234 includes the public key of the universal token102, a name or other identifier for the universal token, an expirationdate, serial number, and identification of the organization which issuedthe certificate. In addition, the digital certificate 234 may include anindication of the security level of the universal token. Thecertification authority signs the digital certificate using its privatekey.

Digital certificate 234 may be generated at the time of manufacture ofthe device or when the universal token 102 is configured for use. Aswould be appreciated by a person of skill in the art, any procedure forgenerating a digital certificate can be used. In an illustrativeexample, the universal token 102 initiates a key enrollment process witha certification authority. During the enrollment process, the universaltoken 102 communicates its public key and optionally identifyinginformation. The certification authority then authenticates the identityof the universal token 102. The verification process can be performed ina variety of ways. For example, when the public/private key pair wasgenerated, processor 260 may share the public key, via a securecommunication link, with a warranty server. In this example, thecertification authority may query the warranty server to validate thatthe received public key is a valid public key for the universal token102. In addition or alternatively, the certification authority mayvalidate the identification information provided by the universal token102.

After the certification authority has authenticated the identity ofuniversal token 102, the certification authority issues a digitalcertificate for universal token 102. As would be recognized by personsof skill in the art, any technique for generating a signed certificatecan be used with the present invention. Note that the public key of thecertification authority must be publicly available to enable validationof the universal token digital certificate 234.

Token-resource authentication data 240 includes authentication datarecords for each resource, service, application, and/or physicallocation to which the user is authorized to access. Token-resourceauthentication data 240 includes a plurality of token-resourceauthentication records. Each record includes a resource identifier 242and its associated authentication data 244. Note that if universal token102 supports multiple users, each record may also include a useridentification field.

Individual records in token-resource authentication data 240 may includedifferent information or have different formats, etc. The type andformat of the authentication data stored for a resource is dependentupon the authentication algorithm and/or method utilized for theresource. In addition, authentication data may store an authenticationalgorithm (e.g., symmetric algorithm) or a pointer to an algorithmstored elsewhere in universal token 102 (e.g., within secure processor260). Universal token 102 is configured to store multiple types andformats for authentication data.

Communications interface 270 is configured to provide an interface forcommunication with authentication tokens 104, devices 106, and/or accessdevices 110. Communications interface 270 may include multiple separateinterfaces. In an embodiment, communications interface 270 includes acontactless or wireless interface. In addition or alternatively,communications interface 270 includes a contact-based or wiredinterface. In an embodiment, the communications interface 270 used totransfer information between authentication tokens 104/devices 106 anduniversal token 102 is also used to transfer information with an accessdevice 110.

FIG. 3 depicts a flowchart 300 of a method for provisioning a universalauthentication token, according to embodiments of the present invention.Through the provisioning method, authentication data stored in anauthentication token 104 or device 106 is transferred to the universaltoken 106. Flowchart 300 is described with continued reference to theexemplary operating environment depicted in FIG. 1 and the exemplaryuniversal authentication token depicted in FIG. 2. However, flowchart300 is not limited to these embodiments. Note that some of the steps inflowchart 300 do not necessarily have to occur in the order shown.

Prior to step 310, a user enrolls with a service provider, employer,building owner, etc. (referred to herein as “provider” for ease ofdescription) for access to a specific resource, service, application, orphysical location (referred to herein as “resource” for ease ofdescription). After performing verification and authentication of theuser, the provider issues an authentication token 104, device 106, ordata file including the authentication data required for future accessto the resource. In addition, to issuing the authentication mechanismthe service provider enrolls an identifier for the user and his/herassociated authentication data in an authentication record for theresource in a server hosting the resource. As a result, a user may havemultiple separate authentication tokens 104 and/or authenticationdevices 106. FIG. 3 provides a method for consolidating theauthentication data from the multiple tokens/devices into a singleuniversal authentication token 102.

In step 310, the importation of authentication data into the universalauthentication token 102 from another authentication token 104 or device106 storing authentication data for a user is initiated. In anembodiment, a user activates a button incorporated into the housing ofthe universal authentication token or a button, link, or similarmechanism displayed on a menu of the universal authentication token toinitiate data importation.

As part of step 310 or prior to step 310, universal token 102 is broughtinto communication contact with the token 104 or device 106 from whichdata is to be imported. For example, universal token 102 may be placedproximate to a an authentication token 104 or device 106 to enablewireless communication between universal token 102 and token 104/device106. In a further example, universal token 102 is physically coupled toan authentication token 104 or device 106 via a connector.

In step 320, a communications connection is established between theuniversal token 102 and token 104/device 106 from which authenticationdata is to be imported. The details of the establishment of thecommunication connection are dependent upon the protocol used forcommunication. In an embodiment, a secure session is established duringstep 320. Alternatively, an insecure session may be first establishedand a secure session established at some later stage of the process, forexample, before sensitive information is transmitted.

In step 330, universal token 102 transmits a request for authenticationdata to the authentication token 104/device 106. The request identifiesat least one resource for which authentication data is requested. In anembodiment, the authentication data stored in an authentication token104/device 106 is associated with a user identifier. In this embodiment,the request from the universal token 102 also includes an identificationof the user. In addition, the request may include information toauthenticate the universal token 102 such as the digital certificate forthe universal token 102.

In step 340, a determination of whether the authentication token104/device 106 receiving the request is enabled to share the requestedauthentication data is made. This step is optional 340. In anembodiment, a flag or similar parameter is set to indicate whether thetoken 104/device 106 is authorized to export stored authentication data.The flag or parameter may be set by the user of the token 104/device106. Alternatively, the flag or parameter may be set at the time ofmanufacture or configuration of the token 104/device 106. If the flag orparameter indicates that exportation is not allowed, operation proceedsto step 345. If the flag or parameter indicates that exportation isallowed, operation proceeds to step 350.

In step 345, the token 104/device 106 communicates a response to therequesting universal token 102 indicating that the request has failed.

In step 350, the token 104/device 106 authenticates the requestinguniversal token 102. In an embodiment, token 104/device 106authenticates the universal token 102 by validating the received digitalcertificate 234 for universal token 102. To validate the digitalcertificate, the token 104/device 106 obtains the public key of thecertification authority which issued the certificate to universal token102. The token 104/device 106 then uses the public key of thecertification authority to verify the signature included with thedigital certificate. If the signature is authentic, universal token 102is successfully authenticated.

In an alternate embodiment, token 104/device 106 authenticates therequesting universal token 102 using a challenge/response protocol. Forexample, token 104/ device 106 may issue a challenge to determinewhether the universal token 102 has the appropriate level of security tostore the authentication data of the token 104/device 106.

FIG. 4 depicts a flowchart 400 of an exemplary certificate-basedchallenge/response protocol, according to embodiments of the presentinvention. Flowchart 400 is described with continued reference to theexemplary operating environment depicted in FIG. 1 and the exemplaryuniversal token 102 depicted in FIG. 2. However, flowchart 400 is notlimited to these embodiments. Note that some of the steps in flowchart400 do not necessarily have to occur in the order shown.

In step 410, the token 104/device 106 generates a random value (ornonce) as a challenge and transmits the challenge to universal token102.

In step 420, universal token 102 forms a hash value of itsidentification, the received random value, and optionally a random value(or nonce) generated by universal token 102.

In step 430, universal token 102 encrypts the hash value with itsprivate key to form a digital signature.

In step 440, universal token 102 transmits the digital signature, randomvalue generated by the universal token 102 (token nonce), andidentification to the token 104/device 106.

In step 450, the token 104/device 106 decrypts the signature with thepublic key for universal token 102. The public key may be transmitted tothe token 104/device 102 in requesting step 330. Alternatively, thetoken 104/device 106 may obtain the public key from a public directory.

In step 455, token 104/device 106 forms a hash value of itsidentification, the generated random value, and optionally the tokennonce. Steps 450 and 455 may occur substantially in parallel.

In step 460, token 104/device 106 compares the hash values generated insteps 450 and 455. If the two values match, the universal token 102 issuccessfully authenticated.

In some embodiments, token 104/device 106 may verify that universaltoken 102 is a secure device. In these embodiments, the manufacturer ofthe universal token 102 may issue a certificate (or include in thedigital certificate) data that indicates the universal token wasmanufactured in a secure manner and has sufficient capabilities tosecurely maintain and use sensitive information. In additionalembodiments, token 104/device 106 may verify that universal token hasthe appropriate security level to store the authentication data.

In an embodiment, a secure communications connection is establishedbetween the universal token 102 and the token 104/device 106.

Returning to FIG. 3, in step 360, token 104/device 106 authenticates theuser of universal token 102. In this step, the token 104/device 106insures that the user of universal token 102 is the user authorized forthe resource whose authentication data is held by token 104/device 106.In an embodiment, token 104/device 106 does not transmit theauthentication data for a user to the universal token 102 unless theuser of the universal token is the same user associated with theauthentication data in the token 104/device 106. Token 104/device 106may further require verification that the user is currently inpossession of the universal token 102 before transmitting authenticationdata. Note that step 360 is optional and may not be present in someembodiments.

FIG. 5 depicts an exemplary flowchart 500 of a method for authenticatingthe user of universal token 102, according to embodiments of theinvention. Flowchart 500 is described with continued reference to theexemplary operating environment depicted in FIG. 1 and the exemplaryuniversal token 102 depicted in FIG. 2. However, flowchart 500 is notlimited to these embodiments. Note that some of the steps in flowchart500 do not necessarily have to occur in the order shown.

In step 510, token 104/device 106 communicates a request to universaltoken 102 for authentication of the user of the device. In anembodiment, token 104/device 106 requests a current biometric (e.g.,fingerprint) scan of the user. In an alternate embodiment, token104/device 106 may request a password, PIN, or a secret shared betweenthe user and the token 104/device 106. As would be appreciated bypersons of skill in the art, other forms of authentication informationmay be requested in this step.

In step 520, the universal token 102 obtains the requested data. Forexample, if biometric data is requested, universal token 102 prompts theuser to initiate a biometric scan (e.g., fingerprint scan) via biometricauthentication interface 250. The universal token 102 then converts thebiometric scan data into a biometric template. In an embodiment,biometric template may be signed using the private key of the universaltoken 102 before it is sent. In a further example, if entry of a sharedsecret is requested, the universal token 102 may prompt the user toenter the shared secret.

In step 530, universal token 102 communicates the user authenticationdata to token 104/device 106. In an embodiment, a secure communicationsession is established. In an embodiment, the authentication data isencrypted prior to transmission using the private key of the universaltoken 102, a secret key established during a negotiation with the token104/106, or some other cryptographic key. In an embodiment, thecommunication to the token 104/device 106 may include data indicatingthat the user authentication data is current. For example, thecommunication or alternatively the signed data, may include a timestamp, sequence number, or other similar form of information.

In step 540, token 104/device 106 verifies the received authenticationdata by comparing the received user authentication data with stored userauthentication data. For example, the token 104/device 106 may compare areceived biometric template or received secret with a biometric templateor secret stored in the token 104/device 106 for the user. In addition,token 104/device 106 may verify the received authentication data iscurrent (e.g., by checking the timestamp). Note that in step 540, thetoken 104/device 106 may also authenticate that the receivedauthentication data came from the universal token 104 (and was nottampered with en route) by authenticating the received digitalsignature.

Returning to FIG. 3, if the authentication of the user was successful,in step 370, the token 104/device 106 transmits the requestedauthentication data for the user to universal token 102. The type ofauthentication data transmitted depends on the type of authenticationused for the resource, application, or service to which theauthentication data applies. For example, the authentication data mayinclude one or more cryptographic keys and one or more current valuesthat are being operated upon by a designated cryptographic algorithm. Inan embodiment, the authentication data may also include anauthentication algorithm.

In step 380, in the authentication record, the authentication data isstored in memory 210 of the universal token 102. The authentication datamay be associated with a user, a provider, and/or a specific resource.

Although FIG. 3 describes the provisioning of data from one token 104 ordevice 106 into universal token 102, a person of skill in the art willrecognize that multiple tokens and/or devices may be provisioned into auniversal token 102 and that such provisioning may be performedsequentially or in parallel.

FIG. 6 depicts a flowchart 600 of a method for using a universalauthentication token, according to embodiments of the invention.Flowchart 600 is described with continued reference to the exemplaryoperating environment depicted in FIG. 1 and the exemplary universalauthentication token depicted in FIG. 2. However, flowchart 600 is notlimited to these embodiments. Note that some of the steps in flowchart600 do not necessarily have to occur in the order shown.

As described above, prior to step 610, a user enrolls with a serviceprovider, employer, building owner, etc. (referred to herein as“provider” for ease of description) for access to a specific resource,service, application, or physical location (referred to herein as“resource” for ease of description). In addition, prior to step 610, theuser provisions a universal authentication token 102 with authenticationdata for multiple resources.

In step 610, universal token 102 is activated. This step is optional. Inan embodiment, universal token 102 includes a biometric authenticationinterface 250. In this embodiment, a biometric template (e.g.,fingerprint template) for the user may be stored in universal token 102.In order to activate universal token 102, a biometric scan of the usermay be taken, a biometric template generated, and compared with a storedbiometric template. If the templates match, the universal token 102 isactivated. In addition or alternatively, the user may be asked to entera password or PIN to activate the universal token.

In step 620, access to a resource is initiated. For example, a user mayinitiate log-in procedures to a website for a financial account. In afurther example, a user may attempt to remotely access computerresources for his/her employer. In another example, a user may attemptto gain access to a restricted area of a building. Access may beinitiated via any device including, but not limited to, a personalcomputer, wireless phone, PDA, personal entertainment device, orspecialized terminal or device.

In step 630, the server or entity hosting the requested resourcerequests authentication.

In step 640, the appropriate resource is selected on the universal token102. In an embodiment, the universal token 102 presents a list of theresources associated with the user on a display. The user then selectsthe appropriate resource from the list. Alternatively, the user may seta switch, press a key, scroll through a menu, etc. to select theappropriate resource. In addition or alternatively, universal token 102automatically selects the appropriate resource based on informationreceived from the hosting server or entity.

In step 650, universal token 102 outputs the authentication data for theresource. In an embodiment, universal token 102 uses the storedauthentication data in conjunction with an authentication algorithm insecure processor to generate the authentication data for output.Universal token 102 may output the authentication data to a reader in anaccess device, as described above (e.g., via a contactless orcontact-based interface). In addition or alternatively, universal token102 may display the authentication data. The user then manually entersthe authentication data into an access device.

In an embodiment, universal token 102 outputs the authentication data inencrypted form. For example, secure processor 260 may use the privatekey of universal token 102 or another key installed in the device whenit was manufactured or configured to encrypt the authentication data.Note that the receiving server must have the complementary key or keys(e.g., public key of universal token 102) to decrypt the authenticationdata upon receipt.

In step 660, the authentication data from the universal token 102 istransmitted to the hosting server or entity. In an embodiment,additional authentication data is provided to the server in this step(e.g., login/password). In this way, the universal token may provide aportion of the authentication in a multi-factor authentication system.

In step 670, the hosting server or entity authenticates the user for therequested resource. For example, the user may be authenticated viacryptographic techniques.

If the user is successfully authenticated, access to the resource isenabled in step 680.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. It will be apparent to persons skilledin the relevant art that various changes in form and detail can be madetherein without departing from the spirit and scope of the invention.Thus, the breadth and scope of the present invention should not belimited by any of the above-described exemplary embodiments, but shouldbe defined only in accordance with the following claims and theirequivalents.

1. A method for provisioning a universal authentication token withauthentication data from a plurality of devices, comprising: (a)establishing a communications connection between the universalauthentication token and a device from which authentication data is tobe imported; (b) transmitting a request for authentication data to thedevice from which authentication data is to be imported; (c)cryptographically authenticating the identity of the universal token tothe device; (d) transmitting user authentication data to the device fromwhich authentication data is to be imported; (e) authenticating theidentity of a user of the universal authentication token to the deviceusing the user authentication data; and (f) receiving the requestedauthentication data if the identity of the universal token and theidentity of the user of the universal authentication token aresuccessfully authenticated.
 2. The method of claim 1, furthercomprising: (g) repeating steps (a) through (f) for at least oneadditional device.
 3. The method of claim 1, wherein the device is anauthentication token.
 4. The method of claim 1, wherein the device is asecond universal authentication token.
 5. The method of claim 1, whereinthe universal authentication token is embedded in a second device. 6.The method of claim 1, wherein the request for authentication dataincludes a digital certificate for the universal authentication token.7. The method of claim 1, wherein step (c) includes: (i) receiving arandom value as a challenge from the device; (ii) forming hash valuefrom an identifier for the universal authentication token and thereceived random value; (iii)encrypting has value with a private key ofthe universal authentication token to form a digital signature; and(iv)transmitting the identifier and the digital signature to the deviceas a response to the challenge.
 8. The method of claim 1, wherein userauthentication data includes a password.
 9. The method of claim 1,wherein user authentication data includes a shared secret.
 10. Themethod of claim 1, wherein user authentication data includes a PIN. 11.The method of claim 1, wherein user authentication data includesbiometric data.
 12. The method of claim 1, wherein the authenticationdata includes one or more cryptographic keys.
 13. The method of claim 1,wherein the authentication data includes an authentication algorithm.14. A universal authentication token for storing authentication data fora plurality of resources, comprising: means for establishing acommunications connection between the universal authentication token andone or more devices from which authentication data is to be imported;means for receiving authentication data from the one or more devices;secure processor including means for cryptographically authenticatingthe identity of the universal token to the device and means forauthenticating the identity of a user of the universal token; and memoryconfigured to store a plurality of resource authentication records, onefor each resource to which the user of the universal authenticationtoken is enrolled.
 15. The universal authentication token of claim 14,wherein at least a portion of the memory is within a security boundaryestablished by the secure processor.
 16. The universal authenticationtoken of claim 14, wherein the memory is further configured to storeuser authentication data.
 17. The universal authentication token ofclaim 14, wherein the universal authentication token is embedded in asecond device.
 18. The universal authentication token of claim 11further comprising: a biometric authentication module.
 19. The universalauthentication token of claim 17, wherein at least a portion of thebiometric authentication module is included within a security boundaryestablished by the secure processor.
 20. The universal authenticationtoken of claim 14 wherein a first authentication record is defined foruse with a first authentication algorithm and a second authenticationrecord is defined for use with a second authentication algorithm.